home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940147.txt < prev    next >
Internet Message Format  |  1994-11-13  |  18KB
  1. Date: Wed, 13 Jul 94 04:30:04 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #147
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Wed, 13 Jul 94       Volume 94 : Issue  147
  11.  
  12. Today's Topics:
  13.                        Bit Regeneration v. DAMA
  14.                            KA9Q/Slip server
  15.                    Managing MSS and Window (2 msgs)
  16.           Managing MSS and Window; IP encapsulation (2 msgs)
  17.                      Speed and Bit regenerators 
  18.  
  19. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  20. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  21. Problems you can't solve otherwise to brian@ucsd.edu.
  22.  
  23. Archives of past issues of the TCP-Group Digest are available
  24. (by FTP only) from UCSD.Edu in directory "mailarchives".
  25.  
  26. We trust that readers are intelligent enough to realize that all text
  27. herein consists of personal comments and does not represent the official
  28. policies or positions of any party.  Your mileage may vary.  So there.
  29. ----------------------------------------------------------------------
  30.  
  31. Date: Tue, 12 Jul 1994 06:50:56 -0500 (CDT)
  32. From: ssampson@sabea-oc.af.mil (Steve Sampson)
  33. Subject: Bit Regeneration v. DAMA
  34. To: tcp-group@UCSD.EDU
  35.  
  36. Barry Gm8SAU/Dc0HK writes:
  37. > As there is an increase in the use of DAMA (csma/cd) Digi's inc latest
  38. > flexnet 3.3a Is there any plans for inclusion to wampes the DAMA mode
  39. > in the ax25 layer
  40.  
  41. Barry points out that bit regeneration and repeaters are a waste of resources.
  42. DAMA would provide the same capability on a half-duplex channel with very
  43. minor AX.25 protocol changes.  I think the TNC coders (Kantronics, AEA) should
  44. make the mode available (DAMA=ON), and probably NOS should run it also (DOS,
  45. Linux). The argument that a router would be better than a repeater is off a
  46. bit, as it assumes the user wants to route.  Some may just want to chat, or
  47. hook up with a (gulp) BBS...  In this case the repeater attempts to solve the
  48. hidden node problem, but so could DAMA, for a lot less.
  49. -- 
  50. Steve
  51.  
  52. ------------------------------
  53.  
  54. Date: Tue, 12 Jul 94 13:35:44 CST
  55. From: "Jan Dolejs" <jandol@mbox.fsv.cuni.cz>
  56. Subject: KA9Q/Slip server
  57. To: tcp-group@ucsd.edu
  58.  
  59. Hi,
  60.  
  61.  
  62. Operations on a dial-slip line in one of distributions of KA9Q-NOS
  63.              (PA0GRI->N1BEE->CWRU->jandol)
  64.  
  65. 1.Overview
  66.  
  67. The aim of usage of this dial-slip line(in connection with a modem) was to
  68. realize running of networks(on Fig. 1). The aims we can divide into several 
  69. groups:
  70.  
  71.  o     the connection of an end-user to the faculty-network, possibly to the
  72.        Internet,
  73.  o     the connection of sublocal Ethernet-network,e.g. Gymnazium for blind,
  74.        any separated department of faculty, home network,etc. to the faculty
  75.        network, possibly to the Internet.
  76.  
  77. The basic idea was a software realizing the user connection to a services
  78. of faculty-network and Internet(e-mail,news,telnet,ftp,gopher,http....etc.)
  79. was undependent on a type of used line.
  80.  
  81.     +-----+                        +-----+       +------+
  82.     | PC  |  ..................    | PC  |       |Cisco |----> Internet
  83.     +--+--+                        +--+--+       +---+--+
  84.        |                  |              |    
  85.  ------+----------------------+-------+--------------+-------- 
  86.                    Faculty    |  Ethernet
  87.                           +---+--+                     | +----+
  88.                           | NOS  |                     +-+ PC |
  89.                           +---|--+                     | +----+
  90.                               M                        |   .
  91.       +----+              ----|----          +------+  |Sublocal
  92.       | PC +-----M-------/         \----M----+ NOS  +--+Ethernet
  93.       +----+            /           \        +------+  |   .
  94.         .              /  Telephone  \                 | +----+
  95.         .             !    network    !                |-+ PC | 
  96.       +----+           \             /                 | +----+
  97.       | PC |-----M------\           /
  98.       +----+             \----|----/
  99.     End users                 M
  100.                               |
  101.                            +--+--+
  102.                            | NOS |
  103.                            +--+--+
  104.                               |
  105.                     --+-------+----------+--
  106.               |                  |    
  107.                     +-+-+ Sublocal     +-+-+
  108.                     |PC | ...........  |PC |
  109.                     +---+ Ethernet     +---+
  110.  
  111.  
  112.   Fig.1. The connection of a telephone network to a faculty network.
  113.  
  114. 2.Phase diagram 
  115.  
  116. In the process of configuring,maintaining and terminating the dial-slip line, 
  117. the dial-slip line goes through several distinct phases:
  118.  
  119.      Attach asy ..    Start slipsv ..
  120.           |               |  Dialer ..
  121.           |               |      |
  122.         +-+-------+     +-+------+--+                +--------------+
  123.         |Dead     | UP  |Establish  |   OPENED       |Authentication|
  124.         |         +---->+           +--------------->|              |
  125.         |---------|     |-----------|                |--------------|
  126.         | Closed  |     |Listen     |                |Opened        |
  127.         +----+----+     +----+--+---+                +--+---+-------+
  128.              ^  Fail/Stop    |  ^ DOWN            Fail  |   |Success
  129.              +<--------------+  |                +------+   |
  130.              |                  |                |          |
  131.              |          +-------+---+            |   +------+-------+
  132.              |  Stop    |Terminate  |   CLOSING  |   |Network       |
  133.              +----------+           +<-----------+---+              |
  134.                         |-----------|                |--------------|
  135.                         |Closing    |                |Open user/gate|
  136.                         +-----------+                +--------------+
  137.  
  138.       Fig.2. Phase diagram
  139.  
  140. This phase diagram is realized by several processes: slip server(slipsv)
  141. and dialer, and in the phase Network bootp daemon too.
  142.  
  143.  
  144. 3.Link Dead
  145.  
  146. This phase begins with the command Attach asy .....(with parameters).Note
  147. that argv[8] must be "d".From this moment circuits(8250,16450,16550) and
  148. interrupt handlers(in,out processes and buffer) are initialised and the 
  149. input process for SLIP line is suspend.The output process is saved in 
  150. memory and new output process discards output data.The process responding
  151. on change of modem(RLSD) signal is not started too.
  152.  
  153. 4.Link establishment phase
  154.  
  155. The precondition for establishing of line is -so called- pasive open line
  156. (LISTEN).Process Slip server(start slipsv ifacename) realizes this 
  157. function. From this moment, dial-slip line is ready for all changes,done
  158. by opening of line. That could be: change of modem signal(RLSD) or an 
  159. activity of administrator or operator(starting of process dialer..).The
  160. process slip server carries out its immer initialization and waits for
  161. RLSD change(to state moved_up).The process dialer...(with parameters)
  162. carries out its synchronization with the process slip server and it does
  163. an usual service for modem and its translation to data mode. This process
  164. holds the line active(option automatical redial) without data discarding.
  165.  
  166. 5.Authentication phase
  167.  
  168. This phase is necessary.It's choosen a simple format for communication between
  169. both ends of line(like in communication with modem in command mode is always
  170. necessary return[\r] on the end of line.This simple communication protocol
  171. starts in moment, when both modems are already in data mode.The slip server
  172. requires the communication after the following scheme(Fig.3).
  173.  
  174.          server                                    client
  175.             |   RLSD in moved_up                      |
  176.             |<---------------                         |
  177.             |                                         |
  178.             |   Verification                          |
  179.             +---------------->                        |
  180.             |                                         |
  181.             |   Username:                             |
  182.             +---------------->                        |
  183.             |                                         |
  184.             |                       uuuuuuu\r         |
  185.             |                      <------------------+
  186.             |   Password:                             |
  187.             +---------------->                        |
  188.             |                       xxxxxxx\r         |
  189.             |                      <------------------+
  190.             |                                         |
  191.             |   slip-server> or                       |
  192.             |   Access denied                         |
  193.             +---------------->                        |
  194.             |                       SLIP\r            |
  195.             |                       <-----------------+
  196.             |                                         |
  197.             |   MTU=                                  |
  198.             +---------------->                        |
  199.             |                                         |
  200.             |                                         |
  201.             |                                         |
  202.  
  203.     Fig.3. Authentication protocol
  204.  
  205. The authentication of line runs by data in file slipuser. The format of line
  206. in this file is similar to format in popusers.
  207. Format:
  208.  
  209. ifacename:Username:Password:Ustype:filterup:filterdn:Uslimit:
  210.  
  211. where:
  212. ifacename ..............name of asy interface
  213. Username ...............user
  214. Password ...............password of user
  215. Ustype   ...............type of user("b" user used bootp,
  216.                                      "a" user not used bootp,
  217.                                      "g" slip-gate)
  218. filterup,filterdn.......files with commands for configuration of IP-filter,
  219.                         filterup is done by opening of line and filterdn by
  220.                         termination of line,
  221. Uslimit  ...............time limit for user.
  222.  
  223. Tab.1. The usage of individual data in the file slipuser, in dependence on 
  224.        user type and type of getting of IP address.
  225.  
  226.     +--------------------+------+-----+-----+--------+---------+-------+
  227.     |    User type       |iface |User |Pass |filterup|filterdn |Uslimit|
  228.     |--------------------|------|-----|-----|--------|---------|-------|
  229.     |b  |Open user |bootp|  x   |  x  |  x  |    x   |    x    |   x   |
  230.     |---|          |-----|------|-----|-----|--------|---------|-------|
  231.     |a  |          |adm  |  x   |  x  |  x  |    x   |    x    |   x   |
  232.     |---|----------|-----|------|-----|-----|--------|---------|-------|
  233.     | g |Open gate |adm  |  x   |  x  |  x  |    -   |    -    |   -   |
  234.     +---+----------+-----+------+-----+-----+--------+---------+-------+
  235.  
  236.     x .... used
  237.     - .... not used
  238.  
  239. 6.Network layer protocol phase
  240.  
  241. If authentication is OK,the line passes to state Network.The usage of IP
  242. protocol is assumed.In this moment we can distinguish following cases:
  243.  
  244.  o     The end user opened the line and it uses BOOTP protocol for assignment 
  245.        of IP address,
  246.  o     The end user opened the line and it does not use BOOTP protocol for
  247.        assignment of IP address,
  248.  o     The dial-slip gateway opened the line.
  249.  
  250. In the first case, the BOOTP server assigns IP address by interface name of
  251. serial line(name asy interface).The slip server fills in(automatically)
  252. routing and arp tables and it uses filters(executes bootp daemon).
  253. In the second case, the network administrator answers the purpose for 
  254. assignment of IP addresss.He must fill in manually data in routing and
  255. arp tables. The slip server executes the usage of filter.
  256. In the third case, the network administrator answers the purpose for setting
  257. of routing and arp tables in both dial-slip gateways.
  258.  
  259. 7.Link termination phase
  260.  
  261. The dial-slip line can be terminated in any moment, by falling down of line
  262. or by operator.Both ends of line find termination, based on change of modem
  263. signal(RLSD to moved_down). The proper termination of line should be carried
  264. out by that end of line,which opened the line(i.e. in case slip-gate:the 
  265. process dialer or in case end user:software phone,umslip etc.).In case
  266. user type "g" are the same systems in both ends(NOS, which work contemporarily
  267. as server and client).It makes no difference, what system starts opening of 
  268. line(proces dialer).The NOS system, opening line must hold the line(automatical 
  269. redial) and must do the proper termination of line.
  270.  
  271. Note:Further information and the distribution(binary) of this software is
  272. available for anonymous by FTP on:
  273. mbox.fsv.cuni.cz(192.108.140.149) /pub/nos
  274. jan.fsv.cuni.cz(192.108.140.148) /pub/nos
  275.  
  276. ------
  277. Jan Dolejs,Charles University,Prague,Czech Republic
  278. e-mail:jandol@mbox.fsv.cuni.cz
  279.        jandol@jan.fsv.cuni.cz
  280.  
  281.  
  282.  
  283.  
  284.  
  285. ------------------------------
  286.  
  287. Date: Tue, 12 Jul 1994 21:22:20 -0500 (CDT)
  288. From: ssampson@sabea-oc.af.mil (Steve Sampson)
  289. Subject: Managing MSS and Window
  290. To: tcp-group@UCSD.EDU
  291.  
  292. In discussing MTU/MSS I put together this list.  Maybe others will want
  293. to comment on it.  The only thing I left out is NOS Segmentation (which
  294. won't work over Net/Rom) and the fact that MSS should be 40 less than the
  295. *Maximum* MTU.  In this case I was tuning it for radio.
  296.  
  297. If you have an Ethernet, I guess that the MTU would be 1500, and MSS will then
  298. be 1460, and thus when talking through an AX.25 to another system with both
  299. radio and Ethernet the two will agree on a 1460 MSS??  Problem there...
  300.  
  301. Sorry if this was beat to death in a previous thread.
  302. -------------------------------------------------------------------------------
  303. This assumes a dependable RF circuit
  304.  
  305. Paclen 256    Not used in datagram mode.
  306.  
  307. Example 1200 baud DG or VC:
  308.  
  309. MTU        256
  310. TCP MSS        216        MTU - 40    40 for IP header
  311. TCP Window    864        MSS * 4
  312.  
  313. Example 1200 baud over Net/Rom VC:
  314.  
  315. MTU        236        PACLEN - 20    20 for Net/Rom header
  316. TCP MSS        196        MTU - 40    40 for IP header
  317. TCP Window    392        MSS * 2 (memory may be problem on Net/Rom)
  318.  
  319. 9600 baud DG or VC over AX.25:
  320.  
  321. MTU        512
  322. TCP MSS        472        MTU - 40
  323. TCP Window    1888        MSS * 4
  324.  
  325. --
  326. Steve, N5OWK
  327.  
  328. ------------------------------
  329.  
  330. Date: Tue, 12 Jul 1994 21:32:25 -0500 (CDT)
  331. From: ssampson@sabea-oc.af.mil (Steve Sampson)
  332. Subject: Managing MSS and Window
  333. To: tcp-group@UCSD.EDU
  334.  
  335. In discussing MTU/MSS I put together this list.  Maybe others will want
  336. to comment on it.  The only thing I left out is NOS Segmentation (which
  337. won't work over Net/Rom) and the fact that MSS should be 40 less than the
  338. *Maximum* MTU.  In this case I was tuning it for radio.
  339.  
  340. If you have an Ethernet, I guess that the MTU would be 1500, and MSS will then
  341. be 1460, and thus when talking through an AX.25 to another system with both
  342. radio and Ethernet the two will agree on a 1460 MSS??  Problem there...
  343.  
  344. Sorry if this was beat to death in a previous thread.
  345. -------------------------------------------------------------------------------
  346. This assumes a dependable RF circuit
  347.  
  348. Paclen 256    Not used in datagram mode.
  349.  
  350. Example 1200 baud DG or VC:
  351.  
  352. MTU        256
  353. TCP MSS        216        MTU - 40    40 for IP header
  354. TCP Window    864        MSS * 4
  355.  
  356. Example 1200 baud over Net/Rom VC:
  357.  
  358. MTU        236        PACLEN - 20    20 for Net/Rom header
  359. TCP MSS        196        MTU - 40    40 for IP header
  360. TCP Window    392        MSS * 2 (memory may be problem on Net/Rom)
  361.  
  362. 9600 baud DG or VC over AX.25:
  363.  
  364. MTU        512
  365. TCP MSS        472        MTU - 40
  366. TCP Window    1888        MSS * 4
  367.  
  368. --
  369. Steve, N5OWK
  370.  
  371. ------------------------------
  372.  
  373. Date: Wed, 13 Jul 1994 01:14:57 -0700
  374. From: Phil Karn <karn@qualcomm.com>
  375. Subject: Managing MSS and Window; IP encapsulation
  376. To: ssampson@sabea-oc.af.mil
  377.  
  378. FYI, I'm probably going to implement Path MTU Discovery in my TCP
  379. fairly soon.
  380.  
  381. By the way, I'd like to survey the NOS variants out there that people
  382. are using to build their wormholes. When I originally wrote that code,
  383. I used IP protocol number 94 to mean "IP on top of IP". I later
  384. discovered that that protocol number normally implies something a
  385. little different, and the preferred protocol number for IP directly on
  386. top of IP is 4. It's used for multicast backbone tunneling, among
  387. other things.
  388.  
  389. Some time ago I redid the receive routine so that NOS would accept
  390. incoming tunneled packets with either PID (4 or 94). The idea was to
  391. get that disseminated so that I could eventually switch the
  392. encapsulating side over to PID 4 without invoking a flag day. Can
  393. people tell me whether the receive-side change has made it yet to the
  394. NOS variants that people are using as wormhole gateways? Or do I need
  395. to keep 94 on the transmit end a little longer to avoid compatibility
  396. problems?
  397.  
  398. Phil
  399.  
  400. ------------------------------
  401.  
  402. Date: Wed, 13 Jul 1994 10:39:38 +0200 (BST)
  403. From: A.Cox@swansea.ac.uk (Alan Cox)
  404. Subject: Managing MSS and Window; IP encapsulation
  405. To: karn@qualcomm.com (Phil Karn)
  406.  
  407. > FYI, I'm probably going to implement Path MTU Discovery in my TCP
  408. > fairly soon.
  409.  
  410. In the light of SIPP/TUBA and the IPng stuff is this actually worth doing,
  411. especially given the number of places it breaks and the number of sites
  412. behind gateways that just do not cope with MTU discovery ?
  413.  
  414. Alan
  415.  
  416. ------------------------------
  417.  
  418. Date: Tue, 12 Jul 1994 08:16:43 -0500
  419. From: rush@dns.sprintcorp.com
  420. Subject: Speed and Bit regenerators 
  421. To: "Milton D. Miller II" <miltonm@bga.com>
  422.  
  423. Milton:
  424.  
  425. I got another reply from my comments about the bit regen, which pointed out
  426. the hidden transmitter bugaboo.  I was familiar with that problem, but I
  427. hadn't considered how the bit regen would have an advantage in such a case.
  428.  
  429. But I would still prefer a cross-frequency solution... but that's obviously
  430. more expensive :-(
  431.  
  432. Thanks for the note.
  433.  
  434. David, rush@erg.sri.com, david@n0oxh.ampr.org
  435.  
  436. ------------------------------
  437.  
  438. End of TCP-Group Digest V94 #147
  439. ******************************
  440.